Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sketch of a subtype judgment on contract specs #747

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

graydon
Copy link
Contributor

@graydon graydon commented Mar 31, 2023

This is a sketch of a subtype relationship on soroban contract specs. The idea here is to support the host function that updates / overwrites contracts with a judgment it can make that a new contract is compatible with the spec (type signature) of an old contract, such that anyone using the old contract will continue to be able to use the new contract.

Of course it's just "spec-level" compatibility, not like "does the contract do the same thing" -- we can't judge that -- but I think it'll prevent a fairly wide class of upgrade mistakes if we can at least catch spec mismatches.

The subtyping relationship here is intended to be extremely textbook and hopefully corresponds to the same rules (covariant returns, contravariant arguments, record extensions, union restrictions) you'll find in any standard treatment of immutable structural types and functions.

We haven't 100% decided we're going to do this yet, I don't think, but I suspect something like this (possibly strengthened or weakened somewhat) will prevent a lot of errors, and I wanted to sketch it out as part of discussing the lifecycle, evolution and versioning of contracts in the field (eg. as part of stellar/rs-soroban-sdk#1095 though that bug somewhat mixes up issues of contract compatibility and SDK compatibility, I think the spec mechanism is likely to be at least part of how we express SDK versioning anyways)

cc @sisuresh, @MonsieurNicolas, @dmkozh and @leighmcculloch

@graydon graydon requested a review from sisuresh as a code owner March 31, 2023 07:00
@leighmcculloch
Copy link
Member

leighmcculloch commented Jun 24, 2023

I think this functionality could live in the soroban-cli. I can imagine the soroban-cli having a subcommand for checking the compatibility of two contracts, either two on disk, or one deployed and one on disk.

I'm hesitant about this living in the host because other than this the host has no knowledge about SDK types or contract interfaces. Adding this logic to the host itself would as far as I can tell make this a part of the protocol proper, rather than being details external to the protocol.

cc @paulbellamy @tsachiherman What do you think about a command in the soroban-cli evaluating the backwards compatibility of two contracts?

@tsachiherman
Copy link

I think that these are very strong "language features" that would be great to add to the cli.
Moreover, for implementing dynamic cross contract calls, I think that these would become useful.
Reading your description, it sounds like a linked list of specEntries. I'm wondering if these could get to a tree like or circular list. ( Since the cli would need to avoid these )

@graydon graydon marked this pull request as draft November 9, 2023 21:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants